The DBMS must terminate user sessions upon user logoff or any other organization or policy-defined session termination events, such as idle time limit exceeded.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-61765	O121-C2-017600	SV-76255r2_rule		Medium

Description
This requirement focuses on communications protection at the application session, versus network packet, level. Session IDs are tokens generated by web applications to uniquely identify an application user's session. Applications will make application decisions and execute business logic based on the session ID. Unique session identifiers or IDs are the opposite of sequentially generated session IDs, which can be easily guessed by an attacker. Unique session IDs help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attackers are unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. When a user logs out, or when any other session termination event occurs, the application must terminate the user session to minimize the potential for an attacker to hijack that particular user session. Database sessions must be terminated when no longer in use in order to prevent session hijacking.

Description

This requirement focuses on communications protection at the application session, versus network packet, level. Session IDs are tokens generated by web applications to uniquely identify an application user's session. Applications will make application decisions and execute business logic based on the session ID. Unique session identifiers or IDs are the opposite of sequentially generated session IDs, which can be easily guessed by an attacker. Unique session IDs help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attackers are unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. When a user logs out, or when any other session termination event occurs, the application must terminate the user session to minimize the potential for an attacker to hijack that particular user session. Database sessions must be terminated when no longer in use in order to prevent session hijacking.

STIG	Date
Oracle Database 12c Security Technical Implementation Guide	2019-09-26

Details

Check Text ( C-62643r1_chk )
Review DBMS settings and vendor documentation to verify user sessions are terminated upon user logout. If they are not, this is a finding. Review system documentation and organization policy to identify other events that should result in session terminations. If other session termination events are defined, review DBMS settings to verify occurrences of these events would cause session termination. If occurrences of defined session-terminating events do not cause session terminations, this is a finding. When a user logs off of an Oracle session gracefully or has the session terminated for an idle timeout or any other reason, the session is terminated, and the resources are returned to the system. Check with the DBA to see what mechanism is used to disconnect the session and what events the site uses to determine if a connection needs to be terminated. To test for timeout, open a connection and leave it idle for a period greater than the defined idle timeout setting enforced by the system. Then try to use the connection. If the connection is no longer active, then the mechanism deployed to terminate the connection is active and working.

Check Text ( C-62643r1_chk )

Review DBMS settings and vendor documentation to verify user sessions are terminated upon user logout. If they are not, this is a finding.

Review system documentation and organization policy to identify other events that should result in session terminations. If other session termination events are defined, review DBMS settings to verify occurrences of these events would cause session termination.

If occurrences of defined session-terminating events do not cause session terminations, this is a finding.

When a user logs off of an Oracle session gracefully or has the session terminated for an idle timeout or any other reason, the session is terminated, and the resources are returned to the system. Check with the DBA to see what mechanism is used to disconnect the session and what events the site uses to determine if a connection needs to be terminated.

To test for timeout, open a connection and leave it idle for a period greater than the defined idle timeout setting enforced by the system. Then try to use the connection. If the connection is no longer active, then the mechanism deployed to terminate the connection is active and working.

Fix Text (F-67681r4_fix)
Configure DBMS settings to terminate sessions upon user logoff. Configure DBMS settings to terminate sessions upon the occurrence of any organization or policy-defined session termination event. - - - - - To configure specific session termination processes, we need to define the organization or policy-defined session termination event. Below are some examples. Oracle has several ways to disconnect idle sessions, both from within SQLPlus via resources profiles (connect_time, idle_time) and with the SQLnet expire time parameter. Can use profiles to set the connect time and idle time with "alter profile" statements: alter profile senior_claim_analyst limit connect_time 15 sessions_per_user 2 ldle_time 10; Profiles comprise a named set of resource limits. By default, when users are created, they are given the default profile, which provides unlimited use of all resources. The syntax to create a profile follows: CREATE PROFILE LIMIT resource_parameters\|password_parameters; Resource_parameters: [SESSIONS_PER_USER n\|UNLIMITED\|DEFAULT] [CPU_PER_SESSION n\|UNLIMITED\|DEFAULT] [CPU_PER_CALL n\|UNLIMITED\|DEFAULT] [CONNECT_TIME n\|UNLIMITED\|DEFAULT] [IDLE_TIME n\|UNLIMITED\|DEFAULT] By setting resource limits, can prevent users from performing operations that will tie up the system and prevent other users from performing operations. Can use resource limits for security, to ensure that users log off the system, so as not to leave the session connected for long periods of time. The system resource limits can be enforced at the session level, the call level, or both. The session level is calculated from the time the user logs on to the database until the user exits. The call level applies to each SQL command issued. Session-level limits are enforced for each connection. When a session-level limit is exceeded, only the last SQL command issued is rolled back; no further work can be performed until a commit, rollback, or exit is performed. Using SQLNET.EXPIRE_TIME The sqlnet.expire_time parameter is used to set a time interval, in minutes, to determine how often a probe should be sent verifying that client/server connections are active. If there is a need to ensure that connections are not left open indefinitely (or up to the time set by operating system-specific parameters), set a value that is greater than 0. This protects the system from connections left open due to an abnormal client termination. When the probe detects a terminated connection or a connection no longer in use, it signals an error, causing the server process to exit. This setting is intended for use on the database server side of the connection, which usually handles multiple connections at any one time. Limitations on using this terminated (dead) connection detection feature are: sqlnet.expire_time cannot be used on bequeathed connections. The SQL*Net expire_time probe packet will generate additional network traffic that may downgrade the network's performance, depending on the number of connections. Depending on the operating system that is in use, additional server processing may need to be performed to distinguish the connection probe from other events that occur. This overhead for detection of probe events can result in downgraded network performance. Turning-on expire_time To set up these advanced features, simply edit the sqlnet.ora file. If a beginner, follow this procedure: Start the Oracle Network Manager GUI. In the GUI navigator pane, expand the icons Local >> Profile. From the list on the right-hand pane, select General. Click on the Advanced tab. Next, enter the values for the fields or options to set. When finished, choose File >> Save Network Configuration to write the changes to the sqlnet.ora file. (Note: This assumes that a single sqlnet.ora file, in the default location, is in use. Please see the supplemental file "Non-default sqlnet.ora configurations.pdf" for how to find multiple and/or differently located sqlnet.ora files.) The sqlnet.ora inbound_connect_timeout parameter The sqlnet.ora inbound_connect_timeout parameter is used to limit the time, set in seconds, for a client to connect with the database server and provide the required authentication information. Also see sqlnet.inbound_connect_timeout tips. To limit consumption of Oracle resources by unauthorized users and enable an audit trail, should set time-limit values for the sqlnet.inbound_connect_timeout parameter in wall-clock seconds. (This parameter does not have default values.) Failure resulting from sqlnet.inbound_connect_timeout will throw an ORA-03136 inbound connection timed out error.

Fix Text (F-67681r4_fix)

Configure DBMS settings to terminate sessions upon user logoff. Configure DBMS settings to terminate sessions upon the occurrence of any organization or policy-defined session termination event.

- - - - -

To configure specific session termination processes, we need to define the organization or policy-defined session termination event. Below are some examples.

Oracle has several ways to disconnect idle sessions, both from within SQL*Plus via resources profiles (connect_time, idle_time) and with the SQL*net expire time parameter.

Can use profiles to set the connect time and idle time with "alter profile" statements:

alter profile senior_claim_analyst limit
connect_time 15
sessions_per_user 2
ldle_time 10;

Profiles comprise a named set of resource limits. By default, when users are created, they are given the default profile, which provides unlimited use of all resources.

The syntax to create a profile follows:

CREATE PROFILE LIMIT resource_parameters|password_parameters;
Resource_parameters:
[SESSIONS_PER_USER n|UNLIMITED|DEFAULT]
[CPU_PER_SESSION n|UNLIMITED|DEFAULT]
[CPU_PER_CALL n|UNLIMITED|DEFAULT]
[CONNECT_TIME n|UNLIMITED|DEFAULT]
[IDLE_TIME n|UNLIMITED|DEFAULT]

By setting resource limits, can prevent users from performing operations that will tie up the system and prevent other users from performing operations. Can use resource limits for security, to ensure that users log off the system, so as not to leave the session connected for long periods of time.

The system resource limits can be enforced at the session level, the call level, or both. The session level is calculated from the time the user logs on to the database until the user exits. The call level applies to each SQL command issued. Session-level limits are enforced for each connection. When a session-level limit is exceeded, only the last SQL command issued is rolled back; no further work can be performed until a commit, rollback, or exit is performed.

Using SQLNET.EXPIRE_TIME

The sqlnet.expire_time parameter is used to set a time interval, in minutes, to determine how often a probe should be sent verifying that client/server connections are active. If there is a need to ensure that connections are not left open indefinitely (or up to the time set by operating system-specific parameters), set a value that is greater than 0. This protects the system from connections left open due to an abnormal client termination.

When the probe detects a terminated connection or a connection no longer in use, it signals an error, causing the server process to exit. This setting is intended for use on the database server side of the connection, which usually handles multiple connections at any one time. Limitations on using this terminated (dead) connection detection feature are:

sqlnet.expire_time cannot be used on bequeathed connections.

The SQL*Net expire_time probe packet will generate additional network traffic that may downgrade the network's performance, depending on the number of connections.

Depending on the operating system that is in use, additional server processing may need to be performed to distinguish the connection probe from other events that occur. This overhead for detection of probe events can result in downgraded network performance.

Turning-on expire_time

To set up these advanced features, simply edit the sqlnet.ora file. If a beginner, follow this procedure:

Start the Oracle Network Manager GUI.

In the GUI navigator pane, expand the icons Local >> Profile.

From the list on the right-hand pane, select General.

Click on the Advanced tab.

Next, enter the values for the fields or options to set.

When finished, choose File >> Save Network Configuration to write the changes to the sqlnet.ora file. (Note: This assumes that a single sqlnet.ora file, in the default location, is in use. Please see the supplemental file "Non-default sqlnet.ora configurations.pdf" for how to find multiple and/or differently located sqlnet.ora files.)

The sqlnet.ora inbound_connect_timeout parameter

The sqlnet.ora inbound_connect_timeout parameter is used to limit the time, set in seconds, for a client to connect with the database server and provide the required authentication information.

Also see sqlnet.inbound_connect_timeout tips.

To limit consumption of Oracle resources by unauthorized users and enable an audit trail, should set time-limit values for the sqlnet.inbound_connect_timeout parameter in wall-clock seconds. (This parameter does not have default values.) Failure resulting from sqlnet.inbound_connect_timeout will throw an ORA-03136 inbound connection timed out error.